Today's business environment places increasing emphasis on computer resources, and the storage and sharing of data. As more and more people become connected to the digital world, the requirements to share and use computer-accessible and stored data is ever more important. In the past, data storage systems were often the sole responsibility of large organizations, such as banks and financial institutions. Today's e-commerce environment however places greater emphasis on the distribution and easy access to data from anywhere in the world.
Data storage and access systems are of particular importance in the e-commerce or e-business world, particularly in such areas as Business-to-Commerce (B2C) and Business-to-Business (B2B) environments. The typical e-commerce application, such as a financial application or a web commerce application, uses and often depends on reliable and efficient access to large amounts of data. In this arena, the database or data repository is the preferred source of data storage. Database systems have been around for many years now, and their importance in the e-commerce environment is well known. Such databases include the Oracle database system from Oracle Systems, and the dB3 database system from IBM. A common feature of most modern database systems is that they allow access from a wide variety of clients and/or other servers, and using a wide variety of application software systems.
Database systems, while great at storing data, would be of little use if they did not provide a mechanism by which data could be easily and efficiently retrieved and/or updated. To this end, many application server providers provide application servers that can be used to allow access to the data on a typical database system. One such application server is the BEA WebLogic Server system from BEA Systems, Inc. San Jose, Calif. Application servers such as WebLogic Server allow software developers to build applications, that are then used to access and/or update data on the database, in accordance with a particular client applications needs. Application servers are of particular use in developing e-commerce applications for distribution or access over the web or Internet. In accordance with a typical scenario, the application server hosts a web server, which in turn supports many web applications. The multitude of clients on the Internet can access this web application to update and/or retrieve data from a database system in communication with the web server. A typical web application may have many hundreds, or thousands, of clients accessing it on a daily basis, and very busy web applications may have thousands of client applications accessing it at the same time. An important consideration when developing application servers and/or databases for providing data is to design them in such a way that this great number of clients can access the data in an efficient manner, without placing too much load on the server itself. Failure to take this into consideration can cause errors in the transaction itself, or delays in processing the transactions. Since in today's environment, a client application (and the user that operates that application) will quickly become frustrated if access to a particular data source is denied, even temporarily, such that and the user may even opt to switch to a different e-commerce provider, the importance of maintaining reliable and efficient connections between a client application and the database or data repository, cannot be underestimated.
The consideration of multiple client, and/or multiple transaction access to single or limited data resources, is of particular importance in on-line transaction processing (OLTP) systems. The term on-line transaction processing system commonly refers to those systems that are accessed in an on-line manner, i.e. over a network or communication link, such as the Internet, and that are used to handle and process transactions originating at a client application for processing at a server. Typically, as part of the transaction, data will be written to, or read from, a database or data repository, which in some instances is considered temporary storage, and in other instances will be a more permanent storage, particularly one in which customer records or data is stored. On-line transaction processing systems include financial applications such as stock trading, and banking applications. In these systems, the high volume of transactions, such as perhaps thousands of simultaneous stock trades, place emphasis on particular areas of the data, particularly when, for example, one or more stocks are hot or are in great demand that day.
When a portion of the database and/or data repository is effected by such high frequency transaction access, the data portion is commonly referred to as a “hot spot”. Hot spots are particularly troublesome for database systems, including OLTP systems, because they create a bottleneck through which many transactions must pass in order to be completed. Although database systems are usually well designed today, such that the transaction will not be created in error, it is relatively common that a hot spot will cause transactions to back up to such an extent that they will fail or freeze, such that the user or client application will be forced to resubmit the transaction again. Of course, as clients retry their transaction the problem may increase, such that the system quickly becomes unusable. Some systems have tried to address this issue, including, for example, the high contention stock trading database system discussed in P. Peinl and A. Reuter, “High contention in a stock trading database: A case study”, In Processing of ACM-SIGMOD 1988 International Conference on Management of Data, Chicago, pages 260-268, June 1988.
However, one of the problems with traditional methods used to minimize or eliminate hot spots, is that they are typically very platform dependent or work at a level within the database that makes them less flexible for use with everyday applications. For example, the high contention stock database described in the Peinl reference cited above, is restricted to use in stock trading systems. Several of the techniques disclosed therein can be extended for use with other on-line transaction processing systems, however the method is difficult to extend to other application server environments. Database manufacturers use internal and often proprietary methods to optimize data access and updates within their database systems themselves, while the application developer typically has little or no means to customize the operation of the database's specific features. Thus, a large degree of control is removed from the application developer and/or the application administrator, when these are the particular people that are best suited to knowing and understanding potential hot spots within their database application and are in the best position to make the most use of available features. As such, any system or method that allows application developers and/or administrators, to easily change the operation of their application, at a layer higher than that of the proprietary database level, to reflect their understanding of the operation of the software, and to minimize potential hot spots, would be of tremendous benefit. The application developer should be able to make use of these features with little or no knowledge of the underlying database structure. The understanding garnished through trial and error, or planning, during the software development process, can be used to support an understanding of the database structure that can be then used with other databases in the future.